Support adding users to user groups at invitation time (AddOrganizationMemberUser / AddProjectMemberUser usergroups) - #9858

Admins can now pick user groups when inviting a user, instead of waiting for
the invite to be accepted and adding the user to groups afterwards.

Backend:
- `AddOrganizationMemberUser` and `AddProjectMemberUser` accept `usergroups`.
  For a pending signup the groups are stored on the org invite (additively
  merged on re-invite) and applied on acceptance; for an existing user they are
  applied immediately in the same transaction.
- A shared resolver validates groups (exist, not managed, admin-role guard) and
  is reused by `AddUsergroupMemberUser`.
- `OrganizationInvite` exposes `usergroups`; `ListUsergroupMemberUsers` lists
  pending invitees with `pending_acceptance`; `RemoveUsergroupMemberUser` works
  on pending invitees; deleting a group scrubs it from pending invites.

CLI:
- `rill user add --group` is repeatable and rides along with the org or project
  invite in one call; the interactive fallback keeps attributes.
- `rill user list` shows groups and attributes on pending invites and a status
  column on group member listings.

Frontend:
- Group multi-select in the Add users and Add guests dialogs.
- Pending rows show their groups; a Manage groups action on every user row.
- The Create and Edit group dialogs list and can add pending invitees.

Backend:
- `AddOrganizationMemberUser` checks membership up front and applies the
  requested groups to an existing member in one transaction, reporting the
  conflict only after the commit; the seat quota is skipped for existing members.
- `DeleteUsergroup` scrubs the group from pending invites in the same
  transaction as the delete.
- Group member counts include pending invitees, matching the member listing.
- `AddUsergroupMemberUser` and `RemoveUsergroupMemberUser` share the group
  resolver and its permission and managed-group checks.

CLI:
- `rill user add --group` treats AlreadyExists as success when the server has
  applied the groups, and rejects attributes on the groups-only path.

Frontend:
- Manage groups dialog snapshots the target user and changes before saving and
  locks the dialog while requests are in flight, so a save can no longer apply
  to a different user.
- Add users dialog treats a 409 with selected groups as a partial success:
  caches are refreshed and the notice says the members were added to the groups.
- Group changes invalidate every variant of the per-user groups query and the
  member lists of the affected groups, so the table dropdown no longer goes stale.
- Pending rows are tagged explicitly instead of relying on invitedBy, and the
  invite coercion is shared between the users and guests pages.
- The group multi-select stops paging after a failed page.

Claude-Session: https://claude.ai/code/session_01UYzyaaSjA9gNrGJXDsCeTs